前言：

對於急迫需要現成方案進行開發的人，個人建議你趕快回頭用 pygame, unity 。因為下面講的內容其實不算是為了遊戲開發，而是為了引擎、系統開發。如果你真的很希望趕快開始遊戲開發的話，查完相關文件就可以快快開始了。

正文：

從 #11 開始發現 python 好像對於 Event-driven 的支援跟我想的不一樣，所以跳下去 survey 很多資料。

修正方向：

1. 尋找使用 python 的 Event loop 方案
2. 了解 Event loop 的底層機制自己實(ㄇㄛˊ)作(ㄋ一ˇ)

其他的 EventSystem, Event-driven, EventLoop 方案

1 的結果不是很順利，訊息很雜
python event driven framework 下去找的結果的前三名
1, 2, 3

出現的方案有：

1. circuits
2. nameko
3. django, ztaskd(by ZeroMQ)
4. twisted
5. ………

從這邊可以發現，雖然這些套件號稱是「事件驅動」，但是用起來的體感還是跟 js 本身提供的 event 不一樣。所以要打造自己想要的事件驅動系統的話，勢必要走2的路線。反向思考，如果官方本身就有提供這方面的標準套件，那其他人也不用辛辛苦苦各自開發自己想用的功能了。

事件迴圈的構成

2 的路線，參照 js 的事件迴圈是如何怎麼完成的？
參照 1, 2 這兩篇。

了解事件迴圈的機制才有機會幫助我們建立屬於自己的事件迴圈系統，我原本以為 js 是用多執行緒，但其實js是 single thread。文章說因為 js 是單線程，完全不能 block 住，所以他裡面的都是 non-blocking I/O ，另外是它為了能夠處理 asynchronous 的東西，把非同步的東西放在 task queue(event queue,callback queue,etc) 裡面處理。另外確保所有同步操作結束之後才會處理非同步的東西。

這篇有談到使用 callback 的 Continuation-passing style (CPS) 是怎麼產生的？當時的時代背景、應用場景。可以參考看看

事件迴圈並不是萬靈丹，而是在一些限制環境(單線程)下的方案。隨著濫用事件造成的 callback hell ，後面採用 Generator, Promise,Async/Await, Coroutine 的設計避開不良的程式設計。

所以「事件」到底是什麼阿？

我目前的理解，「事件」本身比較像是一封信，「事件迴圈」像是郵筒。
有些事件的內容是簡單的事件編號，那可以用 signal 傳送
比較複雜的事件，裡面會附帶參數，那就需要像是 message queue 的方式存放。

事件的傳遞還需要 EventDispatcher，它的角色比較像是郵差先生，把事件轉發給要執行事件的人，callback function。因為使用事件之前要註冊，這樣 EventDispatcher 才知道事件是教由誰處理的？

而事件迴圈是透過「事件佇列」來調度目前要執行的程式。 callback function 送到事件佇列等待被執行。由此構成了整個事件迴圈的運作

今天認識了事件迴圈的概要，後面的實作方向：

1. 模擬送出事件的物件。實作時由 UI 送出，遊戲引擎有自己的事件觸發機制
2. 事件調度者。將收到的事件轉成對應的 callback 放進事件佇列
3. UI介面負責送出事件，主事件迴圈則是不斷消化送到事件佇列裡面的程式
4. 事件迴圈能夠從外部關掉或啟動，不會變成無窮迴圈的失控狀況。

以上，謝謝收看，我們明天見